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BACKGROUND 

From the 1960s and into the early 1980s satellite operations and control were conducted by Air Force Systems 
Command (AFSC), now Air Force Materiel Command (AFMC), out of the Satellite Control Facility at Onizuka 
AFB, CA. AFSC was responsible for acquiring satellite command and control systems and conducting routine 
satellite operations. The daily operations, consisting of satellite health and status contacts and station keeping 
activities, were performed for AFSC by a Mission Control Team (MCT) staffed by civilian contractors who were 
responsible for providing their own technically "qualified" personnel as satellite operators. An MCT consists of 
five positions: mission planner, ground controller, planner analyst, orbit analyst, and ranger controller. Most of 
the training consisted of On-the-job-Training (OJT) with junior personnel apprenticed to senior personnel until 
they could demonstrate job proficiency. With most of the satellite operators having 15 to 25 years of experience, 
there was minimal risk to the mission. 

In the mid 1980s Air Force Space Command (AFSPACECOM) assumed operational responsibility for a newly 
established control node at Falcon AFB (FAFB) in CO. The satellites and ground system program offices (SPOs) 
are organized under AFSC's Space and Missile Systems Center (SMC) to function as a systems engineering and 
acquisition agency for AFSPACECOM. The collection of the satellite control nodes, ground tracking stations, 
computer processing equipment, and connecting communications links is referred to as the Air Force Satellite 
Control Network (AFSCN). 

Unlike AFSC's practice of staffing their MCT with contractors, AFSPACECOM's concept of operations is based on 
Air Force officers serving as the MCT. Furthermore, AFSPACECOM has started transitioning satellite operations 
to Noncommissioned Officers (NCOs). For routine satellite operations, a single Air Force officer will serve as 
space operations crew commander and oversee the activities of several NCO satellite controllers. Because of the 
frequent turnover of military personnel, retaining trained crews for AFSPACECOM presents some unique 
challenges. Initial training and satellite controller position certification became critical issues to AFSPACECOM. 
The training pipeline for AFSPACECOM consists of 12 to 18 months of Formal Undergraduate Space Training 
(UST), 1-3 months Initial Qualification Training (IQT) on the satellite (e.g. Global Positioning System (GPS), 
Defense Support Program (DSP)) and its command and control system, and 30 to 45 days of control center specific 
training. After completion of training, a satellite operator would have only two years to at best two years and ten 
months left on station. Upon completion of their training the students would be qualified crew members ready to 
perform their duties in their Satellite Operations Center (formerly known as the Mission Control Complex (MCC) 
and Test Support Complex (TSC)). 


GENESIS OF SATELLITE OPERATIONS CREW TRAINERS 

In the early 1980s AFSC initiated development of satellite crew trainers to support Air Force satellite launch and 
on-orbit operations. Provisions were also made to interface with NASA to support Air Force /NASA shuttle 
launches and missions. Prior to this time, the standard training method for crew training was to conduct training 
exercise on their operational equipment using a "paper simulation" method. Team members were given paper 
scripts during a training exercise detailing scenarios to which they were to respond (some scripts would provide 
the operator with failed, telemetry values); the operator's appropriate response(s) would then be evaluated. The 
"paper simulation" method was laborious to develop and time consuming to conduct for training large groups of 
teams coordinating over multiple voice-nets and consoles in support of a launch exercise. Unlike the "paper 
simulation” method, crew trainers provide Air Force satellite control teams with a simulated satellite telemetry 
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stream that could be processed and displayed on the crew's command and control system in a dynamic and 
interactive manner. 

Telemetry Simulation System. The Inertial Upper Stage (IUS) Satellite Operations Center (SOC) at OAFB 
became the first program to benefit from the development of a crew trainer, the Telemetry Simulation System 
(TSS). The system was developed by the Unisys Corporation (now PARAMAX Systems Corporation), designed 
using 8086 technology, and required a significant amount of program unique software development. Although 
initially fielded in 1984 for the IUS program, several other satellite application models were developed over the 
succeeding five years. An upgrade to the TSS hosted on 80286 technology was installed at both AFSCN satellite 
control nodes, OAFB and FAFB. 

The TSS was the first Air Force trainer developed for space operations, which supported integrated training 
between the various positions of the SOC crew, the communications segment, and the Resource Control Complex 
(RCC). The TSS had several shortcomings. Each satellite software model was mission unique with very little 
reusable software code between programs. Model development time was from two to three years. Only one 
satellite model could be running at a given time on the TSS. The cost for satellite model development was 
approximately $5M to $7M per satellite application, $1.2 M for the hardware platform, and $3M per installation 
due to the hardware architecture and Air Force facilities and security requirements. The TSS did not simulate Air 
Force ground tracking stations; this limitation made the trainer inadequate for two of the five members of the 
satellite control crew (an orbit analyst who relied on satellite tracking data and a ground controller who needed 
tracking station configuration status information). The TSS software was written in PLM and Intel assembler. 
The code was costly to maintain and was not readily portable to other hardware platforms. Increased training 
and fidelity requirements exceeded TSS hardware architecture capabilities. 

Generic Telemetry Simulator (GTSim). As the development on the TSS was reaching its apex in the middle 
1980s, NASA through a contract with Singer Link (now CAE - Link) began developing the GTSim for the Centaur 
program. Following the Challenger accident, AFSC completed the development of the GTSim to provide the 
reusable, reconfigurable training platform to overcome the shortcomings of the TSS. An application for the 
Defense Satellite Communications Satellite (DSCS) was developed by General Electric under contract with the 
DSCS SPO and deployed in 1992. 

The GTSim again proved the importance of computer simulation to mission success. However, the GTSim did 
not live up to expectations. Development cost for the satellite model were approximately $6 M ($1 M over initial 
projections because very little of the Centaur software could be reused). Installation cost due to unique GTSim 
hardware architecture, and Air Force facility and security requirements were in excess of $2.5 M. The software 
development time increased from one to nearly two years. Like the TSS, there was no ground tracking station 
model in the GTSim. 


THE NEXT GENERATION 

Satellite Control Simulation Study. In the latter part of the 1980s the Satellite Control and Data Handling SPO 
(SMC/ CW) sponsored a study (Satellite Control Simulation Systems Study) exploring areas in which simulation 
and modeling technology could facilitate Air Force satellite control operations. The study concluded that several 
of the capabilities required for simulation and operations could share the same software modules if designed 
properly. For instance a satellite model and supporting orbit propagation models were needed to support 
mission team training, plan validation, and anomaly analysis aids. Software reuse, evolutionary acquisition 
procedures, extensive use of Commercial-Of-The-Shelf (COTS) hardware and software, and a common space 
vehicle application user interface were some of the study's recommendations. For satellite crew trainers the major 
recommendations were to maximize reuse of software simulation models, provide a standard trainer architecture 
for hosting various satellite models, employ rapid satellite modeling development tools to meet mission 
objectives, provide instructional control over telemetry values and training session, and support multiple 
contacts. This study set the course for the development of the next generation crew trainer. 
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Training Systems Working Group. A Training Systems Working Group (TSWG) was established within the Air 
Force Satellite Control community to specify trainer requirements and coordinate activities to promote the 
development of a standard Air Force satellite crew trainer. Its membership was drawn from HQ AFSPACECOM, 
both Air Force satellite control nodes including operators and training personnel, and the Air Force satellite 
ground system and satellite acquisition agencies. The TSWG supported the conclusions of the Satellite Control 
Simulation Systems Study and developed a comprehensive set of operational requirements reflected in an 
AFSPACECOM Statement of Operational Need (SON 012-88, Aug. 90). 

Training Augmentation Device. The opportunity to meet AFSPACECOM’s SON arose when the US. Navy and 
the Air Force jointly funded the Training Augmentation Device (TAD) to provide satellite crew training for Air 
Force SOC crew responsible for operating the Ultra High Frequency Follow-On (UHF F/O) satellite. The 
requirements for the TAD were specified in the 50th SpaceWing Technical Requirements Document (Feb. 91), and 
were translated into system requirements by SMC/CWD (Aug. 91). These requirements focused on providing a 
crew trainer that could simulate the UHF F/O satellite, certain satellite anomalies, and Air Force and Navy 
satellite tracking stations. PARAMAX Systems Corporation was selected to develop the TAD architecture based 
on their in-house prototyping efforts. PARAMAX subcontracted to Hughes Aircraft Company, the UHF F/O 
satellite contractor, to develop the satellite model for the TAD. 

The development strategy for the TAD was based on an evolutionary development concept. While TAD 
requirements were fully flushed out by the user community in the initial stages, design and development would 
occur incrementally. A system design covering the overall software and hardware architecture was scheduled to 
provide the Air Force community insight into the TAD's architecture. Instead of a single massive software 
detailed design, a series of small detailed design meetings were held. The above "evolutionary development" 
approach was initiated to preclude rigidity in specifying a grand design that was likely to be plagued with 
innumerable changes when the actual design implementation occurred. Several critical program milestones were 
established that enabled the contractor to incrementally design and build the TAD architecture. This approach 
enabled the Air Force community to have significant insight and input into the TAD’s architecture throughout its 
development cycle. Installation of TAD hardware at FAFB, completion of TAD’s basic common software models 
and delivery of TAD's UHF satellite models were designated as major prograim milestones. TSWG team 
involvement was maintained throughout the course of the contract. TSWG members participated in the design of 
the TAD's operator interface and satellite component's building block paradigm. This insured user involvement 
in the TAD's design throughout its development. 


SYSTEM DESIGN OVERVIEW 

The primary purpose of the TAD is to provide satellite operations crew readiness training for launch, early-orbit, 
and on-orbit operations in their SOC. The TAD dynamically simulates the external environment to the SOC 
including the ground tracking stations and the satellite. The TAD permits the SOC crew to verify new satellite 
command(s) or command sequences prior to their transmission to a satellite by comparing the satellite's 
simulated response to the predicted response. The TAD supports off-line analysis of satellite anomalies, work 
around procedure, development, and mission planning. TAD satellite subsystem models permit the insertion of 
anomalous states permitting the user to match the actual anomalous condition aboard the satellite. Satellite 
workaround procedures can then be developed by SOC crews and verified against the TAD prior to their 
transmission to the satellite. 

System Design. The TAD's system design is based on the "open systems" architecture approach. The software 
can operate in a single environment (e.g., workstation) or take advantage of a symmetrical multiprocessor 
environment This scalability permits the TAD to address simulation applications that support 1 to N simulated 
objects. Symmetrical multiprocessing using portable parallel processing application software was selected to 
meet Air Force crew trainer growth and performance requirements. Symmetrical multiprocessing under a UNIX 
operating system was selected to meet fixe TAD's performance requirements. The TAD provides classified (red) 
and unclassified (black) data separation. Due to limited available floor space within the SOC, the TAD must be 
located outside the SOC. The TAD is connected to the SOC via the facilities communication segment. 
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Hardware Design. Except for a Multibus I interface to support unique AFSCN interfaces, all of the TAD's 
hardware is composed of COTS equipment. The TAD is hosted on two interconnected Unisys U6085 
minicomputers. One minicomputer runs the ground tracking station network models, while the other 
minicomputer runs the satellite models. The hardware is based on an open systems architecture which permits 
heterogeneous software, scalability of processors, dynamic processor loading and interoperability. TAD's 
software language, operating system, display software file systems, computer interfaces and databases have been 
ported to other UND( operating systems (i.e., Sim, HP and IBM). The U6085 is a parallel processor with four dual 
80486/25 MHz boards capable of 11 Million Instructions Per Second (MIPS). The U6085 provides upward 
scalability to a total of fifteen dual boards per U6085. Each U6085 contains over 1 Giga Byte (GB) removable hard 
drive for storing program unique applications and running in a classified mode. 
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Figure 1. UTAD Hardware Design. 


Connected to each U6085 minicomputer (satellite and network) is an Operator Interface Station (OIS) consisting of 
an IBM RS 6000/520 workstation that provides the human interface. This workstation allows real time 
monitoring of selected data points, injecting anomalies, manipulating simulation models, and changing 
simulation speed. Each workstation contains over 1 GB removable hard disk which contains any program 
specific data, training scripts or classified data. Display of selected satellite telemetry and student interactions is 
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via IBM GT4X 24-bit graphics card. A high speed printer is connected to each RS 6000 to print training data as 
necessary. Connectivity between the U6085s, Multibus I and the RS 6000s is via fiber optics or TCP/IP Ethernet 
LAN. 

The TAD's Multibus I interface is used to connect to the SOC's AFSCN custom data interfaces. The Multibus I is 
composed of commercially available Single Board Computer (SBC) printed circuit boards. A custom board that 
generates TAD satellite telemetry attaches through a standard connector to a commercial Multibus SBC printed 
circuit board. It supports a variety of telemetry formats and telemetry data rates up to 2.5 Mbps. The telemetry 
generator is the only custom piece of hardware in the TAD's architecture. Data rates are programmable and 
encoding schemes are selectable. Telemetry commutation is performed on the host programmable SBC board. A 
Loral NASA Command Formatter (NCF) board resides on the Multibus I and serves as the command ternary 
receive port for SOC satellite commands into the TAD. Six different telemetry boards can be connected to the 
Multibus I, which could be driven by six separate simulations at the same time, thus supporting six different SOC 
training crews. 

Software Design. The software design was predicated on the use of the Ada programming language and 
whenever feasible the use of COTS software to reduce development cost. Use of Ada programming language as 
the main software language was mandatory per DOD policy and Air Force policy. Use of other languages in the 
TAD are limited to special functions or routines such as existing I/O driver software, revised satellite models, 
interfaces to UNIX or COTS software, and fourth generation language (4GL) with Structured Query Language 
(SQL) database code. Two different operating systems support the TAD: U6085 Unisys System V Operating 
System, and the IBM RS 6000 A EX Operating System. Both systems support a security rating of C2 and provide 
discretionary access control, user identification, passwords, and audit trails. The TAD workstation employs 
X-Windows X.11 standard to establish its windowing environment. The user can open several display windows 
on his work station and monitor the status of several on-going activities. X-Windows standardize the manner in 
which a user can open or close display windows permitting increased operator productivity. The workstation’s 
human interface is developed using the Dataviews tool from Visual Intelligence, Inc. Dataviews supports X- 
Windows. 

Database development is supported by the Progress tool from Progress, Inc. The 4GL that is provided by 
Progress inherently supports concurrency control, recovery, import/export of data. The Progress 4GL 
Structured Query Language (SQL) standard is also used to build user data displays and report requests. 

TAD local area network uses a standard IEEE 802.3 Ethernet protocol supporting the Network File System (NFS) 
and Remote Procedure Call (RPC) open standards sponsored by Sun Microsystems, Inc. 

On-line documentation access to the TAD's user manual and another documentation is supported by the desk top 
publishing tool Framemaker, which uses quick look-up hypertext links provided by Frame Technology Inc. 

Telemetry commutation software using PLM software developed for the TSS was adapted into the TAD 
architecture along with the NASA Command Formatter software. Figure 2 identifies the various commercial 
languages by percentage of total lines of code (573.5 KSLOCs) used in the TAD. 
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Ada (36%) 


C (27%) 



Software Architecture. The software is divided into two primary Computer Software Configuration Items 
(CSCI). The TAD's Common User Software (CUS) CSCI includes all those functions which are common among 
satellites, while a separate Mission Unique Software (MUS) CSCI is required for each satellite application model, 
only if a high fidelity capability is required. The CUS models support rapid scripting of TAD simulation models, 
scenario generation and operates with the various COTS software to provide data to the TAD operator 
workstations along with executing satellite and space environment models during simulation run time to support 
telemetry generation and dynamic responses to crew initiated commands. Figure 3 identifies the TAD’s 
Architecture. 
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Figure 3. TAD Architecture. 


Common User Software . The TAD CUS employs Ada tasking model constraints which permit the spawning of 
multiple Ada tasks, each representing a simulation unit (e.g., satellite and tracking stations). When a parallel 
processor environment is present with a parallel Ada run time system, the simulation units takes advantage of the 
additional processors. The TAD's common user software (CUS) consists of a collection of reusable or common 
models such as satellite commanding, orbit line of sight telemetry, orbit dynamics, satellite attitude, satellite 
sensors, actuators, orbit line-of-sight, propulsion electrical power, telemetry, tracking and control, and 
Connectivity models. Figure 4 identifies the TAD's Computer Software Components. A control system based 
block programming paradigm is also provided which permits training personnel to rapidly develop medium 
complexity satellite simulations. 
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Figure 4. TAD Computer Software Components (CSCs). 


The TAD CUS provides die software environment in which all TAD simulation activities take place. A broad 
suite of simulation tools is provided by the CUS such as scripting, logging, script generation from logs, SOC 
interface, simulation control, fast/slow forward time control, common satellite and sub component models, 
simulation state save/restart, multiple simulated time/spatial universes, multiple simulated objects, and 
evaluation utilities and reports. In addition to these features, the TAD CUS provides reconfigurable common 
math/logic models whose behavior is defined through database parameters. The CUS also provides a block 
programming capability that supports modeling of subsystems which have a high degree of variability that 
cannot effectively be handled by the common models. 

Database . The TAD database CSC provides the means by which an operator can enter new data, change existing 
data, or delete data from the MUS database. The MUS database is the data source for tailoring the behavior of the 
simulation environment and the objects which are within the environment. These functions are accomplished by 
Database application code, database load, and the Progress Database development tool modules. 

The Database module provides database management, environment definition, satellite definition, tracking 
station definition, and software discrepancy report/definition. The database manager provides templates from 
which the operator may create new databases which are automatically cataloged. These templates may be created 
for a family of satellites which are similar which are then tailored for specific mission requirements. The software 
discrepancy report/definition function provides on-line identification of hardware or software problems. 

The Database Load module provides a means of uploading actual SOC databases used in the operational 
command and control system directly into the TAD databases. 

The Progress Database development tool, a COTS 4GL client/server product, is used to develop and maintain 
TAD CUS database application code. 

Operator Interface. The operator interface CSC handles all of the processing required to present information to 
and receive directions from the trainer during execution of a training session. These functions are accomplished 
by the Human Interface, Display Processing, Scripting, and Data Views Tool modules. 
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Hie Human Interface module creates a main operations control window which is used by the trainer to initiate a 
training session. Each Operator Instructor Station (OIS) hosts exactly one Human Interface process which 
maintains separate control for each environment and simulated unit that is controlled by that OIS. The Human 
Interface takes advantage of a graphical user interface features such as windowing, mouse-and-menu control, 
and color graphics. 

The Display Processing module is used by the Human Interface module to provide processing of 2-D graphics 
displays. The Scripting module processes any scripts that have been defined for the training session. The 
Data Views Tool module supports the custom development and maintenance of 2-D graphics displays. 

Simulation Engine. The simulation Engine CSC provides the run-time control functions on the compute engine 
(i.e., U6085 minicomputer) which are accomplished by Simulation Engine Control and Ada Task Control 
modules. The Simulation Engine Control module initiates the processes that execute on the minicomputer, 
establishes communication with the OIS, and starts the processes that provide communication with the AFSCN 
interface software components. 

The Ada Task Control module provides control over several module such as the Environment Simulation, the 
Satellite Simulation, and the Tracking Station. It is started by the Simulation Engine Control module when a 
simulated space/time environment is requested. 

Communications. The communications CSC provides the communications interface services between all the 
hardware and software components, regardless of whether they are on the U6085 minicomputer or the RS 6000 
workstation. These functions are accomplished by Ada Communications, Multibus I Communications, and 
Intersubsystem Communications modules. 

The Ada Communications module provides communications between Ada tasks running on the U6085 and UNIX 
processes residing on the RS 6000. The Multibus I Communications module provides communication between 
the TAD system and the Air Force communications switch interface to the SOC. The Intersubsystem 
Communications module provides communication between the U6085 satellite and network subsystems. 

System Services. The system services CSC provides communications, data routing and software utility support 
for TAD software components. These components include system control processes, human interface and display 
handling processes. Multibus I input/output processes, user defined algorithms, space/time environment 
models, and satellite and network subsystem models. These functions are accomplished by Time Control, 
Physical Environment, and Environment Communications modules. The Time Control module provides the OIS 
control over the TAD’s run time environment, such as fast /slow forward, freeze, state save, start /stop. The 
Physical Environment module provides control of the simulation of the necessary physical characteristics of space 
surrounding the earth (e.g., sun, moon and planets). The Environment Communication module provides control 
over communication between objects in the same or different space/ time environments. 

F.nvimnment Simulation. The environment simulation CSC provides the simulation of space/ time environment 
in which the satellite and ground tracking stations operate. The simulation of an environment includes: 
modeling of the passage of time from a specified starting point and the modeling of the necessary physical 
characteristics of space surrounding the earth. 

Data Routing . The data routing CSC provides the transparent exchange of data between TAD components. Each 
simulated unit possess a data pool which has been generated by the Simulation module (Environment, Satellite, 
or Tracking Station) for that unit. Data in an objects data pool can be accessed by any of the TAD’s components. 
It is this loosely coupled nature of the system that provides the flexibility to turn on/ turn off individual models 
and update values in a data pool from alternate means (databases, look-up tables, external sources). 

User-Defined Algorithm fUDAV The user-defined algorithm CSC provides the mechanism for the trainer to 
manipulate data during the execution of a training session. UDAs may be used to generate telemetry 
measurands, manipulate data for display purposes, or generate specific simulation data. UDAs may interact with 
other algorithms and TAD models via the data pools. 
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Satellite Simulation. The satellite simulation CSC provides satellite simulations capable of receiving space vehicle 
commands from a SOC and producing dynamic telemetry output which reflects ongoing evolution of the 
simulation environment and the simulated satellite's response to the received commands. The simulation of a 
satellite includes the modeling of the health and status of various subsystems. Satellite modeling employs 
common math/logic models that obtain satellite-specific characteristics from parameters specified in Hafaha<a>c 
The TAD common satellite subsystem models include: Orbital Dynamics, Attitude, Sensors, Actuators, 
Propulsion, Electrical Power Subsystem, Commanding, Telemetry Processing, Eclipse, Telemetry and 
Commanding Control and Status (TCCS), and a Common Spacecraft Processor Model. These models 
communicate primarily through Data Routing. 

Tracking Station Simulation. The tracking station simulation CSC provides for the simulation of both Air Force 
and Navy satellite tracking stations. These simulations respond to configuration and control directives from the 
SOC and return realistic tracking and status information. This module also provides modeling of core equipment 
and antenna subsystems of the tracking stations. Like the satellite simulation module, this module employs 
common math/logic models that define tracking station-specific characteristics from parameters (tracking station 
coordinates such as longitude, latitude, altitude and obscura data) specified in databases. The TAD common 
tracking station models include: Tracking and Antenna, Command Generation, Tracking Station Control and 
Status (TSCS), and Tracking Station Equipment. 

Mission Unique Software. The TADs Mission Unique Software (MUS) constitutes the specific satellite 
application model (e.g., GPS or UHF F/O). For instance GPS Block I LA software running on the TSS at FAFB 
and totaling 45 KSLOCs of FORTRAN 77 is being transcribed into Ada for use on the TAD. It is scheduled to be 
completed by the Spring of 1994. The total estimate Ada lines is 17.5 KSLOCs. The reason for the significant 
reduction in lines of code is partially due to the nature of Ada being a high order language, but mainly due to the 
ability of TAD’s common models to supplant significant portions of the original FORTRAN code. In the case of 
the UHF F/O satellite model developed by Hughes Aircraft Company, a custom C code to Ada software 
interface was developed. This interface permits the Hughes model (previously developed) to run in the TAD’s 
software environment. The Hughes UHF F/O MUS model consists 100 KSLOCs of C code and is a modification 
of a previously developed satellite simulation for the Hughes HS601 satellite family. 


PROGRAM STATUS 

The TAD development is currently completing development. The TAD hardware and an initial software 
capability was installed in the summer of 1992 at FAFB. A successful demonstration of generating a telemetry 
wavetrain and of receiving SOC commands was completed in February 1993. The Hughes UHF F/O satellite 
model was ported over to the TAD and successfully run with the CUS in a simulation mode at PARAMAX's 
development facility in March 1993. The installation of the basic TAD CUS and UHF F/O MUS is scheduled for 
the* summer of 1993 with an enhanced version of the CUS with the block programming capability scheduled for 
delivery in early 1994. 

Installation of a TAD at OAFB is underway with completion scheduled for the end of 1993. The GPS Block IIA 
software rewrite has started and is expected to be completed by the spring of 1994. The MILSTAR satellite SPO is 
in the planning stages of developing a MILSTAR MUS to support training in their SOC at FAFB. The GPS Joint 
Program Office (JPO) is considering acquiring a TAD to support training at its satellite Master Control Station at 
FAFB along with developing an MUS for its new GPS Block HR satellite. 

An additional use of the TAD is as a test driver in the AFSCN Data Systems test program. A development 
laboratory TAD has been installed at IBM's satellite ground control software maintenance facility to support 
software maintenance and test activities. It is expected to be operational by the summer of 1993. 
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FUTURE DIRECTIONS 


An advantage of the TAD is its portability across hardware platforms. Current technological advances make it 
feasible to port TAD software onto high performance graphic workstations (parallel architecture) and place them 
into the SOC at a significant cost savings over the present hardware architecture. This alternative is being 
investigated. With the TAD being ported to a workstation and located inside the SOC, its facility installation and 
security cost could be significantly reduced. 

The TAD has been adopted as the standard AFSPACECOM crew trainer. Additionally, it has been identified as 
the simulation element for the Air Force's next generation satellite command and control architecture, the 
Advanced Satellite Control (ASC). The ASC stipulates a distributed architecture with heavy reliance on open 
architecture and commercial standards interconnected via high capacity high speed fiber optic data links. 
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